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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the architecture enhancements for Single Radio Voice Call Continuity (SRVCC) 
between E-UTRAN access and 3GPP2's IxCS, and between E-UTRAN access and 3GPP's UTRAN/GERAN accesses 
and between UTRAN (HSPA) access and 3GPP's UTRAN/GERAN accesses, for Circuit Switched (CS) calls that are 
anchored in the IMS. 

This document will not describe 3GPP2 functional entities. However, interfaces between both 3 GPP and 3GPP2 
functional entities are described in this specification. 

SRVCC from E-UTRAN access to 3GPP2 IxCS is covered in this specification. Handling of non- voice component and 
SRVCC from 3GPP2 IxCS to E-UTRAN direction is not specified in this release. 

SRVCC from E-UTRAN/UTRAN (HSPA) access to 3GPP UTRAN/GERAN CS accesses for voice calls that are 
anchored in the IMS, as well as the coordination between the SRVCC for voice call and the handover of non- voice PS 
bearers, are covered in this specification. The handover of non- voice PS bearer from E-UTRAN is specified by the 
procedures defined in TS 23.401 [2], TS 23.060 [10], TS 25.413 [11] and TS 43.129 [12]. The handover of non voice 
PS bearer from UTRAN (HSPA) is specified by the procedures defined in TS 23.060 [10], TS 25.413 [11] and 
TS 43.129 [12]. Handling of SRVCC from 3GPP UTRAN/GERAN CS accesses to E-UTRAN/UTRAN (HSPA) 
direction is not specified in this release. The handling of multiple simultaneous voice bearers with SRVCC is not 
supported in this release. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.401 : "GPRS enhancements for E-UTRAN access" . 

[3] 3 GPP TS 23.402 "Architecture enhancements for non-3 GPP accesses". 

[4] 3GPP2 X.S0042-0: "Voice Call Continuity between IMS and Circuit Switched System". 

[5] ITU-T Recommendation 1.130: "Method for the characterization of telecommunication services 

supported by an ISDN and network capabilities of an ISDN" . 

[6] ITU-T Recommendation Q.65: "Methodology - Stage 2 of the method for the characterisation of 

services supported by an ISDN" . 

[7] 3GPP TR 36.938: "Improved Network Controlled Mobility between E-UTRAN and 

3GPP2/Mobile WiMAX Radio Technologies". 

[8] 3GPP2 A.S0008-C: "InteroperabiHty Specification (lOS) for High Rate Packet Data (HRPD) 

Radio Access Network Interfaces with Session Control in the Access Network". 

[9] 3GPP TS 22.278: "Service requirements for the Evolved Packet System (EPS)". 

[10] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 



ETSI 



3GPP TS 23.216 version 8.3.0 Release 8 7 ETSI TS 123 216 V8.3.0 (2009-03) 

[11] 3GPP TS 25 .4 1 3 : "UTRAN lu interface Radio Access Network Application Part (RANAP) 

signalling". 

[12] 3GPP TS 43.129: "Packet-switched handover for GERAN A/Gb mode; Stage 2". 

[13] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) CentraHzed Services: Stage 2". 

[14] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity: Stage 2". 

[15] 3GPP TS 23.002: "Network Architecture". 

[16] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 

[17] Void. 

[18] 3GPP TS 23.009: "Handover procedures". 

[19] 3GPP TS 25.331: "Radio Resource Control (RRC) protocol specification". 

[20] 3GPP2 A.S0014: "Interoperability Specification (lOS) for cdma2000 Access Network Interfaces". 

[21] 3GPP TS 33.210: "3G Security; Network Domain Security; IP network layer security". 

[22] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security architecture". 

[23] 3GPP TS 48.008: "Mobile Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 

specification" . 

[24] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)". 

[25] 3GPP TS 33.102: "3G Security; Security architecture". 

[26] 3GPP TS 22.173: " IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

IxCS: The 3GPP2 legacy circuit switched signalHng system as defined in 3GPP2 X.S0042-0 [4]. 

3GPP SRVCC UE: A 3GPP SRVCC UE is a UE enhanced for IMS Service Continuity with the additional UE 
capabilities described in this specification for SRVCC between E-UTRAN and 3 GPP UTRAN and / or between E- 
UTRAN and 3GPP GERAN and / or between UTRAN (HSPA) and 3GPP UTRAN and 3GPP GERAN. 

Single Radio Voice Call Continuity: Voice call continuity between IMS over PS access and CS access for calls that 
are anchored in IMS when the UE is capable of transmitting/receiving on only one of those access networks at a given 
time. 

Session Transfer Number for SR-VCC (STN-SR): see TS 23.237 [14]. 
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3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

SRVCC Single Radio Voice Call Continuity 

IxCS IWS Single Radio Voice Call Continuity Interworking solution Function for 3GPP2 IxCS 



4 High level Principles and Concepts 

4.1 High level Principles 

4.1.1 Architectural Principles for 3GPP2 1 xCS SRVCC 

The solution for SRVCC fulfils the requirements of TS 22.278 [9] and the following architectural principles: 

1. The solution shall allow coexistence and be compatible with the IxCS procedures specified in the 3GPP2 VCC 
specification, X.S0042 [4]. 

2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs. 

3. The solution shall be transparent to E-UTRA only terminal or network. 

4. The solution shall minimize the coupling between the E-UTRAN and the 3GPP2 access. In particular, the 
solution shall allow the cdma2000 IxRTT Rev A specification to evolve without necessitating a modification to 
the E-UTRAN specifications. 

5. RAT change and domain selection should be under network control. 

6. In roaming cases, the Visited PLMN should control the RAT change and/or domain selection while taking into 
account any related HPLMN policies. 

7. The solution shall not impact cdma2000 RAT. 

8. The solution shall not impact cdma2000 CS CN. 

4.1 .2 Architectural Principles for 3GPP UTRAN/GERAN SRVCC 

The solution for SRVCC fulfils the requirements of TS 22.278 [9] and the following architectural principles: 

1. The solution shall allow coexistence and be compatible with TS 23.292 [13] and TS 23.237 [14]. 

2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs. 

3. RAT change and domain selection should be under network control. 

4. E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN handover for SRVCC is triggered by the same radio handover 
conditions and mechanisms as for an E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN PS handover. 

NOTE: The UE may have multiple voice media streams that are carried over multiple voice (e.g. QCI=1) bearers 
or are multiplexed over a single voice bearer. Only one of these voice streams is selected for SRVCC by 
the sec AS (see TS 23.237 [14]). 
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4.2 Concepts 

4.2.1 E-UTRAN and 3GPP2 1xCS SRVCC 

For SRVCC-capable UEs, the call is always anchored at the VCC AS in the 3GPP2's IMS. The 3GPP2 IxCS IWS 
enables a single radio UE to communicate in parallel both with the source system and the target system. From VCC 
perspective, this mechanism minimizes the voice gap by supporting the transport of signalling for establishment of the 
target CS access leg while the terminal is connected to the source PS access network. 



Originating Side 



Target Side 




E-UTRAN 



EUTRAN/EP3 tunnelling 



1xCS signalling 
messages tunnelled 
across EUTRAN / 
EPS 




1xCS 
IWS 



S102 tunnelling 



1xRTT 
MSC 



1xCS signalling 
messages tunnelled 
inside S102 protocol 



Registration and 
Authorization if needed 



CS Call setup procedures 



Towards 
VLR/HLR 



Call terminated 
> at VCC AS 



VCC AS STARTS 

VCC Domain Transfer 

PROCEDURES 



A1 messages 



Figure 4.2.1-1 : Transport of 3GPP2 IxCS signalling messages for preparation of the CS access leg in 

the target system 

The S102 reference point is used to convey 3GPP2 IxCS signalling messages between the MME and 3GPP2 IxCS 
IWS. These Ix CS signalling messages are actually exchanged between the UE and the 3GPP2 IxCS IWS, and S102 is 
only one link in the overall UE-lxCS IWS tunnelling path. On the remaining portion of the tunnelling path, the 3GPP2 
IxCS signalling messages are encapsulated in E-UTRAN/EPS tunnelling messages (UE-MME). 

4.2.2 E-UTRAN and 3GPP UTRAN/GERAN SRVCC 

For facilitating session transfer (SRVCC) of the voice component to the CS domain, the IMS multimedia telephony 
sessions needs to be anchored in the IMS. 

For SRVCC from E-UTRAN to UTRAN/GERAN, MME first receives the handover request from E-UTRAN with the 
indication that this is for SRVCC handling, and then triggers the SRVCC procedure with the MSC Server enhanced 
with SRVCC via the Sv reference point if MME has SRVCC STN-SR information for this UE. MSC Server enhanced 
for SRVCC then initiates the session transfer procedure to IMS and coordinates it with the CS handover procedure to 
the target cell. MSC Server enhanced for SRVCC then sends PS-CS handover Response to MME, which includes the 
necessary CS HO command information for the UE to access the UTRAN/GERAN. 

Handling of any non- voice PS bearer is done by the PS bearer splitting function in the MME. MME starts the handover 
of non-voice PS bearer during SRVCC procedure based on the information received from E-UTRAN. The handover of 
non-voice PS bearer(s), if performed, is done as according to Inter RAT handover procedure as defined in TS 
23.401 [2]. The MME is responsible to coordinate the Forward Relocation Response from SRVCC and PS-PS handover 
procedure. 
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Figure 4.2.2-1 : Overall high level concepts for SRVCC from E-UTRAN to UTRAN/GERAN 

4.2.3 UTRAN (HSPA) to 3GPP UTRAN/GERAN SRVCC 

For facilitating session transfer (SRVCC) of the voice component to the CS domain, the IMS multimedia telephony 
sessions needs to be anchored in the IMS. 

For SRVCC from UTRAN (HSPA) to UTRAN/GERAN, SGSN first receives the handover request from UTRAN 
(HSPA) with the indication that this is for SRVCC handling, and then triggers the SRVCC procedure with the MSC 
Server enhanced with SRVCC via the Sv if SGSN has STN-SR information for this UE. MSC Server enhanced for 
SRVCC then initiates the session transfer procedure to IMS and coordinates it with the CS handover procedure to the 
target cell. MSC Server enhanced for SRVCC then sends PS-CS handover Response to SGSN, which includes the 
necessary CS HO command information for the UE to access the UTRAN/GERAN. 

Handling of any non voice PS bearer is done by the PS bearer splitting function in the SGSN. SGSN starts the handover 
of non voice PS bearer during SRVCC procedure based on the information received from UTRAN (HSPA). The 
handover of non voice PS bearer(s), if performed, is done as according to Inter/Intra RAT handover procedure as 
defined in TS 23.060 [10] and TS 25.413 [11]. The SGSN is responsible to coordinate the Forward Relocation 
Response from SRVCC and PS-PS handover procedure. 
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Figure 4.2.3-1 : Overall high level concepts for SRVCC from UTRAN (HSPA) to UTRAN/GERAN 



Architecture model and reference points 



5.1 



General 



The SRVCC Architecture for 3GPP2 IxCS reuses many existing elements in 3GPP2 X.S0042 [4] for 3GPP2 IxCS. 

The SRVCC Architecture for 3GPP UTRAN/GERAN reuses the session transfer function defined for IMS in 
TS 23.237 [14] for IMS service continuity. 

The overall model and impacts to the various elements is provided in the following clauses. 



5.2 



Reference architecture 



5.2.1 E-UTRAN and 3GPP2 1xCS SRVCC architecture 

This specification introduces an additional functional entity to those defined in the E-UTRAN architecture 
TS 23.402 [3], called Ix CS SRVCC interworking solution function (3GPP2 IxCS IWS), see figure 5.2.1-1. 

NOTE: The figure only shows the necessary components related to 3GPP2 IxCS IWS. 
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SIP signalling 
Bearer before HO 
Bearer after HO 



Tunnelled IxRTT messages 



Figure 5.2.1-1 : SRVCC architecture for E-UTRAN to 3GPP2 IxCS 

5.2.2 E-UTRAN and 3GPP UTRAN/GERAN SRVCC architecture 

This specification introduces an additional function to those defined in the E-UTRAN architecture TS 23.401 [2] for 
SRVCC. This additional function is provided by the MSC Server (i.e., MSC Server enhanced for SRVCC). 

NOTE 1 : The following figure only shows the necessary components related to MSC Server enhanced with 
SRVCC. 



UE Um/Uu ISCg^ 

^^ UTRAN/GERAN 




E-UTRAN Uu 



Bearer path before HO 

Bearer path after HO 

SIP signaling path before HO 



NOTE 2 
NOTES 
NOTE 4 



MSC Server shown in the figure is enhanced for SRVCC. 

This architecture also applies to roaming scenario (i.e., S8, S6a are not impacted due to SRVCC). 

The MSC server enhanced with SRVCC may not be the final target MSC which connects to the target cell. 

Figure 5.2.2-1 : SRVCC architecture for E-UTRAN to 3GPP UTRAN/GERAN 
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5.2.3 UTRAN (HSPA) and 3GPP UTRAN/GERAN SRVCC architecture 

This specification introduces an additional function to those defined in the UTRAN architecture TS 23.060 [10] for 
SRVCC. This additional function is provided by the MSC Server (i.e., MSC Server enhanced for SRVCC). 
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Figure 5.2.3-1 : SRVCC architecture for UTRAN (HSPA) to 3GPP UTRAN/GERAN with Gn based SGSN 
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NOTE 4 



The above figures only show the necessary components related to MSC Server enhanced with SRVCC. 

MSC Server shown in the above figures are enhanced for SRVCC. 

This architecture also applies to roaming scenario. 

The MSC server enhanced with SRVCC may not be the final target MSC which connects to the target cell. 



Figure 5.2.3-2: SRVCC architecture for UTRAN (HSPA) to 3GPP UTRAN/GERAN with S4 based SGSN 



5.3 



Functional Entities 



NOTE 1: 3GPP2 components are not described here. Please refer to 3GPP2 X.S0042 [4]. 

NOTE 2: IMS components are not described here. Please refer to TS 23.237 [14] and TS 23.292 [13]. 

5.3.1 3GPP2 1x CS SRVCC interworking solution function (1xCS IWS) 

3GPP2 IxCS IWS uses the S102 reference point to communicate with the MME and to transport 3GPP2 IxCS 
signalling messages to the SRVCC UE. The role of the 3GPP2 IxCS IWS is: 

- To be a signalling tunnelling end point towards the MME for receiving/sending encapsulated 3GPP2 IxCS 
signalling messages to/from the UE; and 

- To emulate a IxRTT BSS towards the IxRTT MSC (reference point Al as defined in 3GPP2 A.S0014 [20] 
between IxBS and MSC). 
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5.3.2 MSC Server enhanced for E-UTRAN and 3GPP UTRAN/GERAN 
SRVCC 

In addition to the standard MSC Server behavior defined in TS 23.002 [15], an MSC Server which has been enhanced 
for SRVCC provides the following functions as needed for support of SRVCC: 

- Handling the Relocation Preparation procedure requested for the voice component from MME via Sv reference 
point; 

- Invoking the session transfer procedure from IMS to CS as according to TS 23.237 [14]; 

- Coordinating the CS Handover and session transfer procedures; 

- Handling the MAP_Update_Location procedure without it being triggered from the UE. 

5.3.3 MME 

5.3.3.1 Interworking with 3GPP2 1xCS IWS 

If the MME (operator) supports interworking to 3GPP2 IxCS, the MME shall follow the rules and procedures described 
in TS 23.402 [3] with the following additions and clarifications: 

- To be a signalling tunnelling end point towards the 3GPP2 IxCS IWS for sending/receiving encapsulated 3GPP2 
IxCS signalling messages to/from the UE, which are encapsulated in SI -MME SI Information Transfer 
messages (TR 36.938 [7]). 

- release of the E-UTRAN resources after SRVCC to the 3GPP2 IxCS is completed. 

5.3.3.2 Interworking with 3GPP MSC Server enhanced for SRVCC 

5.3.3.2.1 Interworking with 3GPP IVISC Server enhanced for SRVCC 

If the MME (operator) supports the interworking to 3GPP CS, the MME shall follow the rules and procedures described 
in TS 23.401 [2] with the following additions and clarifications: 

- Performing the PS bearer splitting function by separating the voice PS bearer from the non- voice PS bearers. 

- Handling the non- voice PS bearers handover with the target cell as according to Inter RAT handover procedure 
as defined in TS 23.401 [2]. 

- Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv 
interface. This procedure is only triggered once regardless of the number of voice bearers (i.e. QCI=1) that are in 
use by the UE.. 

- Coordinating PS handover and SRVCC handover procedures when both procedures are performed, 

5.3.3.2.2 PS bearer splitting function 

The function identifies the voice PS bearer upon E-UTRAN to UTRAN/GERAN SRVCC and separates it from the non- 
voice PS bearers. 

5.3.3A SGSN 

5.3.3A.1 Interworking with 3GPP MSC Server enhanced for SRVCC 

5.3.3A.1 .1 Interworking with 3GPP MSC Server enhanced for SRVCC 

If the SGSN (operator) supports the interworking to 3GPP CS, the SGSN shall follow the rules and procedures 
described in TS 23.060 [10] with the following additions and clarifications: 
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- Performing the PS bearer splitting function by separating the voice PS bearer from the non- voice PS bearers. 
VoIP is detected by traffic class=conversational and SSD='speech'. 

- HandHng the non- voice PS bearers handover with the target cell as according to Inter/Intra RAT handover 
procedure as defined in TS 23.060 [10]. 

- Initiating the SRVCC handover procedure for handover of the voice component to the target cell via the Sv 
interface. This process is only triggered once regardless of the number of PS voice bearers (i.e. SSD='speech') 
that are in use by the UE.. 

- Coordinating PS handover and SRVCC handover procedures when both procedures are performed. 

5.3.3A.1 .2 PS bearer splitting function 

The function identifies the voice PS bearer upon HSPA to UTRAN/GERAN SRVCC and separates it from the non- 
voice PS bearers. 

5.3.4 UE enhanced for SRVCC 

5.3.4.1 Interworking with 3GPP2 1xCS 

If the UE supports 3GPP2 IxCS access, the IxCS SRVCC UE is a UE that is capable to perform SRVCC to the 3GPP2 
IxCS system. The interaction between UE and E-UTRAN is described in TR 36.938 [7]. The interaction with the 
3GPP2 IxCS system is described in this specification. 

5.3.4.2 Interworking with 3GPP UTRAN/GERAN 

3GPP SRVCC UE is needed to perform SRVCC (see clause 3.1 for 3GPP SRVCC UE definition). The interaction 
between UE and E-UTRAN is described in TS 36.300 [16] and between UE and UTRAN (HSPA) is described in 
TS 25.331 [19]. 

3GPP SRVCC UE shall support UE assisted T-ADS functionality as described in TS 23.292 [13] for selecting the CS 
domain for terminating voice calls. 

The SRVCC UE indicates to the network that the UE is SRVCC capable when being configured for using IMS speech 
service supported by the home operator, e.g. the IMS Multimedia Telephony Service for bi-directional speech as 
described in TS 22.173 [26] and the operator policy on the SRVCC UE as specified in TS 23.237 [14] does not restrict 
the session transfer. 

5.3.5 Serving/PDN GW 

No additional requirement due to SRVCC. 

5.3.6 E-UTRAN 

5.3.6.1 Interworking with 3GPP2 1xCS 

If the E-UTRAN (operator) supports interworking to 3GPP2 IxCS, the E-UTRAN performs the HO trigger, tunnelling 
of the 3GPP2 IxCS signalling messages toward the MME, and interacting with the SRVCC UE as described in 
TR 36.938 [7]. 

E-UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of established QCI=1 bearers for a specific UE. An example algorithm is provided in clause A.l. 

NOTE: If E-UTRAN does not update the neighbour cell list dynamically, if E-UTRAN triggers handover to Ix 

when either the "SRVCC operation possible" indication is set to "false" or there are no established QCI=1 
bearers for a specific UE, this will result in an error case. 
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5.3.6.2 Interworking with 3GPP UTRAN/GERAN 

Between UE and E-UTRAN, no additional functionality is required for the E-UTRAN as defined in TS 36.300 [16]. 

When E-UTRAN selects a target cell for SRVCC handover, it needs to send an indication to MME that this handover 
procedure requires SRVCC 

E-UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of established QCI=1 bearers for a specific UE. An example algorithm is provided in clause A.2. 

NOTE: In case E-UTRAN does not update the neighbour cell list dynamically, if E-UTRAN triggers handover to 
a VoIP-incapable cell when the "SRVCC operation possible" indication is set to "false" and there are 
established voice (QCI=1) bearers for a specific UE, the establishment of the voice bearers will be 
rejected by the target access. 

5.3.6A UTRAN (HSPA) 

When HSPA capable UTRAN selects a target cell for SRVCC handover, it needs to send an indication to SGSN that 
this handover procedure requires SRVCC. 

NOTE 1: UTRAN (HSPA) assumes that SGSN supports SRVCC functionality. 

UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication 
and/or presence of established voice bearers (i.e. bearers with Traffic Class = Conversational and Source Statistic 
Descriptor = 'speech') for a specific UE. An example algorithm is provided in clause A.3. 

NOTE 2: In case UTRAN does not update the neighbour cell list dynamically, if UTRAN triggers handover to a 
VoIP-incapable cell when the "SRVCC operation possible" indication is set to "false" and there are 
established bearers with Traffic Class = Conversational and Source Statistic Descriptor = 'speech' for a 
specific UE, the establishment of the voice bearers will be rejected by the target access. 

5.3.7 HSS 

5.3.7.1 Interworking with 3GPP UTRAN/GERAN 

The SRVCC STN-SR and MSISDN are downloaded to MME from HSS during E-UTRAN attach procedure. For 
UTRAN (HSPA), the STN-SR and MSISDN are downloaded to SGSN from HSS during GPRS attach procedure. 

NOTE: HSS functionality is not impacted when MSC Server enhanced with SRVCC performs the 
MAP_Update_Location procedure. 

5.4 Reference points 

5.4.1 MME-3GPP2 1xCS IWS (S102) 

The S102 reference point provides a tunnel between MME and 3GPP2 IxCS IWS to relay 3GPP2 IxCS signalling 
messages. Ix CS signalling messages are those messages that are defined for A21 interface as described in 3GPP2 
A.S0008-C [8]. 

NOTE. It is up to stage 3 to determine whether the tunnelling protocol for S102 can be defined as exactly as in 
A21. If so, SI 02 is then equivalent to A21. 

5.4.2 MME - MSC Server (Sv) 

The Sv reference point provides SRVCC support between 3GPP E-UTRAN/UTRAN (HSPA) and 3GPP 
UTRAN/GERAN. 
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5.4.3 E-UTRAN - MME (S1 -MME) 



For 3GPP2 IxCS SRVCC, the Sl-MME reference point provides SI Information Transfer message (TR 36.938 [7]) 
between UE and MME to relay the 3GPP2 IxCS signalHng messages. 

For 3GPP SRVCC, the Sl-MME reference point allows handover signalling between E-UTRAN and MME. It is 
defined in TS 36.300 [16] 



5.4.3A UTRAN (HSPA) - SGSN (lu-ps) 



For 3GPP HSPA SRVCC, the lu-ps reference point allows handover signalling between UTRAN and SGSN. It is 
defined in TS 25.413 [11]. 



5.4.4 HSS-MME(S6a) 



For 3GPP SRVCC, the s6a is used to download SRVCC related information to MME during E-UTRAN attach 
procedure. 



6 Procedures and flows 

6.1 SRVCC from E-UTRAN to 3GPP2 1xCS 

6.1 .1 E-UTRAN Attach procedure for SRVCC 

E-UTRAN attach procedure for 3GPP2 SRVCC UE is performed as defined in TS 23.401 [2] with the following 
additions: 

- SRVCC UE includes the SRVCC capability indication as part of the UE network capability in the Attach 
Request message. MME stores this information for SRVCC operation. 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.1 .2 Service Request procedures for SRVCC 

Service Request procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 [2] with the following 
additions: 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.1 .3 Call flows for SRVCC from E-UTRAN 

Figure 6.1.3-1 illustrates a high-level call flow for the E-UTRAN-to-lx voice service continuity procedure. 
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Figure 6.1.3-1 : LIE VolP-to-lx CS voice service continuity 

1. Ongoing VoIP session over the IMS access leg established over EPS/E-UTRAN access. 

2. IxCS SRVCC UE sends measurement reports to eNB. 

3. The E-UTRAN (e.g., based on some trigger, measurement reports) makes a determination to initiate an 
inter- technology handover to cdma2000 IxRTT Rev A. 

4. The E-UTRAN signals the UE to perform an inter-technology handover by sending a Handover from EUTRA 
Preparation Request (3Glx Overhead Parameters, RAND value) message. 

5. The UE initiates signalling for establishment of the CS access leg by sending a Handover from EUTRA 
Preparation Request (3Glx Overhead Parameters, RAND value) message. 

6. The E-UTRAN sends an UpHnk SI cdma2000 Tunnelling (MEID, RAND, Ix Origination, Reference CelllD) 
message to the MME. 

7. Upon reception of the Uplink SI cdma2000 TunnelHng message, the MME selects a 3GPP2 IxCS IWS based on 
Reference CelllD and encapsulates the Ix Origination Message along with the MEID and RAND in a S 102 
Direct Transfer message (as "Ix Air Interface Signalling"). 

8. The traffic channel resources are established in the Ix RTT system and 3GPP2 IxCS procedures for initiation of 
Session Transfer are performed as per 3GPP2 X.S0042 [4]. 

NOTE 1: Step 9 and 3GPP2 IxCS procedures in step 8 are independent of each other. 

NOTE 2: The " VDN" parameter referred to in 3GPP2 X.S0042 [4] corresponds to the STN-SR parameter defined 
in TS 23.237 [14]. 

9. The 3GPP2 IxCS IWS creates a Ix Handoff Direction message and encapsulates it in a S102 Direct Transfer 
message (as "Ix Air Interface Signalling"). 
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10. The MME sends the Ix Handoff Direction message embedded in a DownUnk SI cdma2000 Tunnelling message 
to the E-UTRAN. 

1 1. The E-UTRAN forwards the Ix Handoff Direction message embedded in a MobiHty from EUTRA Command 
message to the UE. This is perceived by the UE as a Handover Command message. 

12. Once the UE receives the traffic channel information from the cdma2000 IxRTT Rev A system, the UE retunes 
to the IxRTT radio access network and performs traffic channel acquisition with the IxRTT CS access (e.g., 
IxRTT BSS). 

13. The UE sends a IxRTT handoff completion message to the IxRTT CS access (e.g., IxRTT BSS). 

14. The IxRTT CS Access sends message to IxRTT MSC to indicate of handoff done. The resources between Ix CS 
IWS and IxRTT MSC may be released at this step. 

15. Ongoing voice call over the CS access leg established over IxRTT access. The E-UTRAN/EPS context may be 
released based on the normal E-UTRAN/EPS procedure. 

16. The eNodeB sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates the SI 
release procedure is caused by handover from E-UTRAN to IxRTT. 

17. The MME exchanges Suspend Request/ Acknowledge messages with the Serving GW. The Sl-U bearers are 
released for all EPS bearers and the GBR bearers are deactivated by the MME. The non-GBR bearers are 
preserved and are marked as suspended in the S-GW. Upon receipt of downlink data the S-GW should not send a 
downlink data notification message to the MME. 

18. SI UE Context in the eNodeB is released as specified in TS 23.401 [2]. 

6.2 E-UTRAN and 3GPP GERAN/UTRAN SRVOC 
6.2.1 E-UTRAN Attach procedure for SRVCC 

E-UTRAN attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.401 [2] with the following 
additions: 

- SRVCC UE includes the SRVCC capability indication as part of the UE Network Capability in the Attach 
Request message, if the UE has been configured for using IMS speech service supported by the home operator 
and the session transfer is not restricted and maintained during Tracking Area Updates. MME stores this 
information for SRVCC operation. The procedures are as specified in TS 23.401 [22]. If the UE has not been 
configured to use an IMS speech service supported by the home operator or the session transfer is restricted, the 
SRVCC UE shall not include the SRVCC capability. 

NOTE: If the operator policy on the UE is changed, the UE can change its SRVCC capability indication as part of 
the UE network capability in a Tracking Area Update message. 

- SRVCC UE includes the GERAN Classmark (if GERAN access is supported) in the Attach Request message 
and maintained during Tracking Area Update. 

- If the subscriber is allowed to have SRVCC in the VPLMN then HSS includes SRVCC STN-SR and MSISDN 
in the Insert Subscriber Data message to the MME. 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 

6.2.1 A Service Request procedures for SRVCC 

Service Request procedures for 3GPP SRVCC UE are performed as defined in TS 23.401 [2] with the following 
additions: 

- MME includes a "SRVCC operation possible" indication in the SI AP Initial Context Setup Request, meaning 
that both UE and MME are SRVCC-capable. 
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6.2.2 Call flows for SRVCC from E-UTRAN 

NOTE 1: If the MSC Server enhanced for SRVCC controls the target BSS/RNS, the steps depicted with dot-dashed 
arrows representing the MSC-MSC handover procedure defined in TS 23.009 [18] are not executed and 
the functions of the MSC Server enhanced for SRVCC are merged with those of the target MSC. 

NOTE 2: For the sake of brevity the call flow descriptions use "MSC Server" instead of "MSC Server enhanced for 
SRVCC". 

NOTE 3: The target MSC need not be enhanced for SRVCC. 

6.2.2.1 SRVCC from E-UTRAN to GERAN without DTM support 

Depicted in figure 6.2.2.1-1 is a call flow for SRVCC from E-UTRAN to GERAN without DTM support. 
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Figure 6.2.2.1-1 : SRVCC from E-UTRAN to GERAN without DTM support 

1 . UE sends measurement reports to E-UTRAN. 

2. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to GERAN. 

3. Source E-UTRAN sends Handover Required (Target ID, generic Source to Target Transparent Container) 
message to the source MME. The E-UTRAN places the "old BSS to new BSS information IE" for the CS 
domain in the generic Source to Target Transparent Container. The container type also indicates to the MME 
that this is a SRVCC handover operation only towards the CS domain. 

4. Based on the QCI associated with the voice bearer (QCI 1) and the type of generic container, the source MME 
splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice 
bearer only towards MSC Server; 
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5. The MME sends a SRVCC PS to CS Request (STN-SR, MSISDN, generic Source to Target Transparent 
Container, MM Context) message to the MSC Server. The MSC server is selected based on the Target ID 
received in the Handover Required message. The MME received STN-SR and MSISDN from the HSS as part of 
the subscription profile downloaded during the E-UTRAN attach procedure. The MM Context contains security 
related information. CS security key is derived by the MME from the E-UTRAN/EPS domain key as defined in 
TS 33.401 [22]. The CS Security key is sent in the MM Context. 

6. The MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a 
Prepare Handover Request message to the target MSC. 

7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge 
messages. 

8. Target MSC sends a Prepare Handover Response message to the MSC Server. 

9. Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. 
using ISUP lAM and ACM messages. 

10. The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP lAM (STN-SR) 
message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 1: This step can be started after step 8. 

NOTE 2: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the 
subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 in 
TS 23.292 [13]). 

1 1. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point. 

12. Source IMS access leg is released as per TS 23.237 [14]. 
NOTE 3: Steps 1 1 and 12 are independent of step 13. 

13. MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source MME. Source MME knows that at the end of the PS-CS handover the non-GBR bearers should be 
preserved. 

14. Source MME sends a Handover Command (Target to Source Transparent Container) message to the source E- 
UTRAN. The message includes information about the voice component only. 

15. Source E-UTRAN sends a Handover from E-UTRAN Command message to the UE. 
16.UEtunestoGERAN. 

17. Handover Detection at the target BSS occurs. 

18. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2 and if ISR is activated the 
TLLI and RAI pair are derived from the GUTI as described in TS 23.401 [2]. This triggers the Target SGSN to 
send a Suspend Request message to the Source MME. The MME returns a Suspend Response to the Target 
SGSN. The MME also starts the preservation of non-GBR bearers and the deactivation of the voice bearer. 

19. Target BSS sends a Handover Complete message to the target MSC. 

20. Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

21. Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

22. MSC Server sends a SRVCC PS to CS Complete Notification message to the source MME, informing it that the 
UE has arrived on the target side. Source MME acknowledges the information by sending a SRVCC PS to CS 
Complete Acknowledge message to the MSC Server. 
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23. MSC Server may perform a MAP Update Location to the HSS/HLR if needed. This may be needed for MSC 
Server to receive GSM Supplementary Service information and routing of mobile terminating calls properly in 
certain configuration. 

NOTE 4: this Update Location is not initiated by the UE. 

After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060 [10]) the UE shall 
resume PS services by sending a Routeing Area Update Request message to the SGSN. The Update Type depends on 
the mode of operation of the GERAN network, e.g. in mode I a Combined RA/LA Update is used and in mode II or III 
Routeing Area Update is used. 

6.2.2.1 A SRVCC from E-UTRAN to GERAN with DTM but without DTM HO support 

The call flow for this scenario is similar to the call flow depicted in figure 6.2.2.1-1, with the exception that the Suspend 
procedure (step 18 in figure 6.2.2.1-1) is not performed. At the end of the procedure described in figure 6.2.2.1-1, the 
UE re-establishes the PS resources by performing the Routing Area update procedure as described in TS 23.060 [10]. 



6.2.2.2 



SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support 



Depicted in figure 6.2.1.2-1 is a call flow for SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support, 
including the handling of the non-voice component. 
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Figure 6.2.2.2-1 : SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support 

1 . UE sends measurement reports to E-UTRAN. 

2. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to 
UTRAN/GERAN. 
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3. If target is UTRAN, the source E-UTRAN sends a Handover Required (Target ID, generic Source to Target 
Transparent Container) message to the source MME. E-UTRAN also indicates to MME that this is for CS+PS 
HO. 

NOTE 1 : This indication is required because the single transparent container alone is not sufficient for the MME to 
know if this is a request for a PS-only HO, or a request for a CS+PS HO. When the source E-UTRAN 
indicates that this is a CS+PS HO request, the source MME sends the single received transparent 
container to both the target CS domain and the target PS domain. 

If target is GERAN, the source E UTRAN sends a Handover Required (Target ID, generic Source to Target 
Transparent Container, additional Source to Target Transparent Container) message to the source MME. The 
E-UTRAN places the "old BSS to new BSS information IE" for the CS domain in the additional Source to 
Target Transparent Container. In this case, the MME identifies from the number of received transparent 
containers that this is a request for a CS+PS handover, so no further indication is required. 

4. Based on the QCI associated with the voice bearer (QCI 1) and the number of received containers and the HO 
indication (if the target is UTRAN), the source MME splits the voice bearer from all other PS bearers and 
initiates their relocation towards MSC Server and SGSN, respectively. 

5a) Source MME initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS 
Request (Target ID, STN-SR, MSISDN, Source to Target Transparent Container, MM Context) message to the 
MSC Server. The MSC server is selected based on the Target ID received in the Handover Required message. 
The Target ID is also used by the MSC Server to identify the target RNS/BSS. The message includes 
information relevant to the CS domain only. MME received STN-SR and MSISDN from the HSS as part of the 
subscription profile downloaded during the E-UTRAN attach procedure. MM Context contains security related 
information. CS security key is derived by the MME from the E-UTRAN/EPS domain key as defined in 
TS 33.401 [22]. The CS Security key is sent in the MM Context. 

5b) MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a 
Prepare Handover Request message to the target MSC. 

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover 
Request (additional Source to Target Transparent Container) message to the target RNS/BSS. 

6. In parallel to the previous step the source MME initiates relocation of the remaining non- voice PS bearers. The 
following steps are performed (for details see TS 23.401 [2] clauses 5.5.2.1 and 5.5.2.3): 

a) Source MME sends a Forward Relocation Request (Source to Target Transparent Container, MM Context, 
PDP Context) message to the target SGSN. The PDP Context includes information for the non-voice 
component only. The handling of security keys for PS handover of the remaining non-voice PS bearers is 
specified in TS 33.401 [22]. 

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

7. After the target RNS/BSS receives both the CS relocation/handover request with the PS relocation/handover 
request, it assigns the appropriate CS and PS resources. The following steps are performed: 

a) Target RNS/BSS acknowledges the prepared PS relocation/handover by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target SGSN. 

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the 
source MME. 

8. In parallel to the previous step the following steps are performed: 

a) Target RNS/BSS acknowledges the prepared CS relocation/handover by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target MSC. 

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the 
MSC Server. 
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c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server 
e.g. using ISUP lAM and ACM messages. 

NOTE 2: The Target to Source Transparent Container sent to the target SGSN is step 7a and the Target to Source 
Transparent Container sent to the target MSC in step 8a, include the same allocation of CS and PS 
resources (e.g. the target BSS includes the same DTM Handover Command in both containers). 

9. The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP lAM (STN-SR) 
message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session 
Transfer, TS 23.237 [14]. 

NOTE 3: This step can be started after step 8b. 

NOTE 4: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the 
subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 of 
TS 23.292 [13]). 

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at 
this point. 

11. The source IMS access leg is released according to TS 23.237 [14]. 
NOTE 5: Steps 10 and 1 1 are independent of step 12. 

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source MME. 

13. Source MME synchronises the two prepared relocations and sends a Handover Command (Target to Source 
Transparent Container) message to the source E-UTRAN. 

NOTE 6: When the target cell is GERAN, the MME may receive different Target to Source Transparent Containers 
from the MSC Server and from the SGSN, i.e. a "New BSS to Old BSS Information" (see 
TS 48.008 [23]) may be received from the MSC Server and a "Target BSS to Source BSS Transparent 
Container" (see TS 48.018 [24]) may be received from the SGSN. 

14. E-UTRAN sends a Handover from E-UTRAN Command message to the UE. 

15. UE tunes to the target UTRAN/GERAN cell. 

16. Handover Detection at the target RNS/BSS occurs. 

17. The CS relocation/handover is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to the target MSC. 

b) Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

c) Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

d) MSC Server sends a SRVCC PS to CS Complete Notification message to the source MME. Source MME 
acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC 
Server. 

e) MSC Server may perform an MAP Update Location to the HSS/HLR if needed. This may be needed for the 
MSC Server to receive GSM Supplementary Service information and routing of mobile terminating calls 
properly in certain configuration. 

NOTE 7: This Update Location is not initiated by the UE. 

18. In parallel to the previous step, the PS relocation/handover is completed. The following steps are performed: 
a) Target RNS/BSS sends Relocation Complete/Handover Complete message to target SGSN. 
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b) Target SGSN sends a Forward Relocation Complete message to the source MME. Source MME 
acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the 
target SGSN. 

c) Target SGSN updates the bearer with Serving GW as specified in TS 23.401 [2]. 

6.3 UTRAN (HSPA) and 3GPP GERAN/UTRAN SRVOC 

6.3.1 GPRS Attach procedure for SRVCC 

GPRS attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.060 [10] with the following additions: 

- SRVCC UE includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach 
Request message, if the UE has been configured to use an IMS speech service supported by the home operator 
and the session transfer is not restricted and maintained during Routeing Area Updates. SGSN stores this 
information for SRVCC operation. If the UE has not been configured to use an IMS speech service supported by 
the home operator or the session transfer is restricted, the SRVCC UE shall not include the SRVCC capability. 

NOTE: If the operator policy on the UE is changed, the UE can change its SRVCC capability indication as part of 
the UE network capability in a Routing Area Update message. 

- UTRAN (HSPA) receives UE SRVCC capability indication as part of the "UE Radio Access Capability". 

- If the subscriber is allowed to have SRVCC in the VPLMN then HSS includes STN-SR and MSISDN in the 
Insert Subscriber Data message to the SGSN. 

6.3.2 Call flows for SRVCC from UTRAN (HSPA) 

NOTE 1: If the MSC Server enhanced for SRVCC controls the target BSS/RNS, the steps depicted with dot-dashed 
arrows representing the MSC-MSC handover procedure defined in TS 23.009 [18] are not executed and 
the functions of the MSC Server enhanced for SRVCC are merged with those of the target MSC. 

NOTE 2: For the sake of brevity the call flow descriptions use "MSC Server" instead of "MSC Server enhanced for 
SRVCC". 

NOTE 3: The target MSC need not be enhanced for SRVCC. 

6.3.2.1 SRVCC from UTRAN (HSPA) to GERAN without DTM support 

Depicted in figure 6.3.2.1-1 is a call flow for SRVCC from HSPA to GERAN without DTM support. 
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Figure 6.3.2.1-1 : SRVCC from UTRAN (HSPA) to GERAN without DTM support 

1. UE sends measurement reports to Source UTRAN (HSPA). 

2. Based on UE measurement reports the source UTRAN (HPSA) decides to trigger a handover to GERAN. 

3. Source UTRAN (HSPA) sends Relocation Required (Source to Target Transparent Container) message to the 
source SGSN. The UTRAN (HSPA) places the "old BSS to new BSS information IE" for the CS domain in 
Source to Target Transparent Container. The container type also indicates to the MME that this is a SRVCC 
handover operation only towards the CS domain. 

4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the type 
of Source to Target Transparent Container, the source SGSN splits the voice bearer from the non- voice bearers 
and initiates the PS-CS handover procedure for the voice bearer only towards MSC server. 

5. Source SGSN sends a SRVCC PS to CS Request (STN-SR, MSISDN, Source to Target Transparent Container, 
MM Context) message to the MSC Server. The MSC server is selected based on the Target ID received in 
Relocation Required message. SGSN received the STN-SR and MSISDN from the HSS as part of the 
subscription profile downloaded during the UTRAN (HSPA) attach procedure. The MM Context contains 
security related information. The CS Security key is derived by SGSN from the UTRAN (HSPA)/EPS domain 
key as defined in TS 33.102 [25].The CS security key is sent in the MM Context. 

6. The MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a 
Prepare Handover Request message to the target MSC. 

7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge 
messages. 

8. Target MSC sends a Prepare Handover Response message to the MSC Server. 
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9. Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. 
using ISUP lAM and ACM messages. 

10. The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP lAM (STN-SR) 
message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 1: This step can be started after step 8. 

NOTE 2: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the 
subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 of 
TS 23.292 [13]). 

1 1. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point. 

12. Source IMS access leg is released according to TS 23.237 [14]. 
NOTE 3: Steps 1 1 and 12 are independent of step 13. 

13. MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source SGSN. Source SGSN knows that at the end of the PS-CS handover the other GPRS bearers (i.e. non 
VoIP) should be preserved. 

14. Source SGSN sends a Relocation Command (Target to Source Transparent Container) message to the source 
UTRAN (HSPA). The message includes information about the voice component only. 

15. Source UTRAN (HSPA) sends a Handover Command message to the UE. 
16.UEtunestoGERAN. 

17. Handover Detection at the target BSS occurs. 

18. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2 and if ISR is activated the 
TLLI and RAI pair are derived from the GUTI as described in TS 23.401 [2]. This triggers the Target SGSN to 
send a Suspend Request message to the Source SGSN. The Source SGSN returns a Suspend Response to the 
Target SGSN. The Source SGSN also starts the preservation of non-GBR bearers and the deactivation of the 
voice bearer. 

19. Target BSS sends a Handover Complete message to the target MSC. 

20. Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

21. Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

22. MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN, informing it that the 
UE has arrived on the target side. Source SGSN acknowledges the information by sending a SRVCC PS to CS 
Complete Acknowledge message to the MSC Server. 

23. MSC Server may perform a MAP Update Location to the HSS/HLR if needed. This may be needed for MSC 
Server to receive GSM SS information and routing of mobile terminating calls properly in certain configuration. 

NOTE 4: This Update Location is not initiated by the UE. 

After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060 [10]) the UE shall 
resume GPRS services by sending a Routeing Area Update Request message to the SGSN. The Update Type depends 
on the mode of operation of the GERAN network, e.g. in mode I a Combined RA/LA Update is used and in mode II or 
III Routeing Area Update is used. 
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6.3.2.1a SRVCC from UTRAN (HSPA) to GERAN with DTM but without DTM HO 
support 

The call flow for this scenario is similar to the call flow depicted in figure 6.3.2.1-1, with the exception that the Suspend 
procedure (step 18 in figure 6.3.2.1-1) is not performed. At the end of the procedure described in figure 6.3.2.1-1, the 
UE re-establishes the PS resources by performing the Routing Area update procedure as described in TS 23.060 [10]. 



6.3.2.2 



SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support 



Depicted in figure 6.3.1.2-1 is a call flow for SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO 
support, including the handling of the non voice component. 
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Figure 6.3.2.2-1 : SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support 

1. UE sends measurement reports to Source UTRAN (HSPA). 

2. Based on UE measurement reports the source UTRAN (HSPA) decides to trigger a handover to 
UTRAN/GERAN. 

3. If target is UTRAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, Source to Target 
Transparent Container) message to the source SGSN. UTRAN (HSPA) also indicates to SGSN that this is for 
CS+PS HO. 

NOTE 1 : This indication is required because the single transparent container alone is not sufficient for the MME to 
know if this is a request for a PS-only HO, or a request for a CS+PS HO. When the source UTRAN 
(HSPA) indicates that this is a CS+PS HO request, the source SGSN sends the single received transparent 
container to both the target CS domain and the target PS domain. 

If target is GERAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, generic Source to 
Target Transparent Container, additional Source to Target Transparent Container) message to the source SGSN. 
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The UTRAN (HSPA) places the "old BSS to new BSS information IE" for the CS domain in the additional 
Source to Target Transparent Container. In this case, the SGSN identifies from the number of received 
transparent containers that this is a request for a CS+PS handover, so no further indication is required. 

4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the 

number of received containers and the HO indication (if the target is UTRAN), the Source SGSN splits the voice 
bearer from all other PS bearers and initiates their relocation towards MSC Server and SGSN, respectively. 

5a) Source SGSN initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS 
Request (Target ID, STN-SR, MSISDN, Source to Target Transparent Container, MM Context) message to the 
MSC Server. The MSC server is selected based on the Target ID received in the Handover Required message. 
The Target ID is also used by the MSC Server to identify the target RNS/BSS. The MSC server is selected based 
on the Target ID received in the Relocation Required message. The message includes information relevant to the 
CS domain only. SGSN received STN-SR and MSISDN from the HSS as part of the subscription profile 
downloaded during the UTRAN (HSPA) attach procedure. MM Context contains security related information. 
The CS Security key is derived by the SGSN from the UTRAN (HSPA)/EPS domain key as defined in 
TS 33.102 [25]. The CS security key is sent in the MM Context. 

5b) MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a Prepare 
Handover Request message to the target MSC. 

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

6. In parallel to the previous step the source SGSN initiates relocation of the remaining non- voice PS bearers. The 
following steps are performed (for details see TS 23.060 [10]): 

a) Source SGSN sends a Forward Relocation Request (Source to Target Transparent Container, MM Context, 
PDP Context) message to the target SGSN. The PDP Context includes information for the non-voice 
component only. The handling of security keys for PS handover of the remaining non-voice PS bearers is 
specified in TS 33.102 [25]. 

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover 
Request (Source to Target Transparent Container) message to the target RNS/BSS. 

7. Target RNS/BSS coordinates the CS relocation request with the PS relocation request and assigns resources. The 
following steps are performed: 

a) Target RNS/BSS acknowledges the prepared PS relocation by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target SGSN. 

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the 
source SGSN. 

8. In parallel to the previous step the following steps are performed: 

a) Target RNS/BSS acknowledges the prepared CS relocation by sending the Relocation Request 
Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the 
target MSC. 

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the 
MSC Server. 

c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server 
e.g. using ISUP lAM and ACM messages. 

9. The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP lAM (STN-SR) 
message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session 
Transfer, see TS 23.237 [14]. 

NOTE 2: This step can be started after step 8b. 
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NOTE 3: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the 
subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 of 
TS 23.292 [13]). 

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access 
leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at 
this point. 

11. The source IMS access leg is released according to TS 23.237 [14]. 
NOTE 4: Steps 10 and 1 1 are independent of step 12. 

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the 
source SGSN. 

13. Source SGSN synchronises the two prepared relocations and sends a Relocation Command (Target to Source 
Transparent Container) message to the source UTRAN (HSPA). 

14. UE tunes to the target UTRAN/GERAN cell. 

15. UTRAN (HSPA) sends a Handover Command message to the UE. 

16. Handover Detection at the target RNS/BSS. 

17. The CS relocation is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to the target MSC. 

b) Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through 
connected in the MSC Server/MGW according to TS 23.009 [18]. 

c) Completion of the establishment procedure with ISUP Answer message to the MSC Server according to 
TS 23.009 [18]. 

d) MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN. Source SGSN 
acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC 
Server. 

e) MSC Server may perform an MAP Update Location to the HSS/HLR if needed. This may be needed for the 
MSC Server to receive GSM SS information and routing of mobile terminating calls properly in certain 
configuration. 

NOTE 5: this Update Location is not initiated by the UE. 

18. In parallel to the previous step, the PS relocation is complete. The following steps are performed: 

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to target SGSN. 

b) Target SGSN sends a Forward Relocation Complete message to the source SGSN. Source SGSN 
aclmowledges the information by sending a Forward Relocation Complete Acknowledge message to the 
target SGSN. 

c) Target SGSN updates the bearer with GGSN. 



7 Charging 

See TS 23.292 [13] clause on charging for guidance on the handling of charging for SRVCC. 
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8 Handover Failure 

8.1 Failure in EUTRAN and 3GPP UTRAN/GERAN SR-VOC 

8.1 .1 Failure before MSC Server initiates Session Transfer 

If a failure is encountered before the MSC Server initiates Session Transfer, then the standardised handover failure 
procedures apply according to TS 23.401 [2]. No further action is required by the UE. 

8.1 .2 Failure after UE receives HO command 

If the UE encounters a failure after it receives the handover command and does not successfully transition to 3GPP 
UTRAN/GERAN, the UE attempts to return to E-UTRAN, according to standardised procedures and initiates signalling 
to transfer the session back to E-UTRAN using the service continuity procedures described in TS 23.237 [14]. The core 
network (MME, MSC Server) shall take no SR-VCC specific action in the event of not receiving the Handover 
Complete message from the UE. 

8. 1 .3 Handover Cancellation 

If the source eNodeB decides to terminate the handover procedure before its completion, the MME shall return to its 
state before the handover procedure was triggered. The MME attempts to trigger, at the MSC Server enhanced for 
SRVCC, handover cancellation procedures according to TS 23.009 [18]. The MSC Server enhanced for SRVCC shall 
take no SRVCC-specific action towards IMS. 

In order to recover from potential handover cancellations, the SRVCC UE monitors the user plane for unexpected 
termination (e.g. the media flow stops when still in coverage). The UE may automatically attempt to re-establish the 
session by operating as though it required a transfer of the session to E-UTRAN, according to the service continuity 
procedures described in TS 23.237 [14]. If the session is no longer active, then this session transfer request shall be 
rejected by the IMS. 



9 Security 

9.1 Network Domain Security with 3GPP2 IxGS IWS 

Network domain security with 3GPP2 IxCS IWS shall be provided by NDS/IP according to TS 33.210 [21] with 
integrity protection and confidentiality. This shall be applied whenever signalling messages (e.g. containing security 
context) are transferred on the SI 02 reference point. 

NOTE 1: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection 
according to TS 33.210 [21]. 

9.2 Network Domain Security with 3GPP UTRAN/GERAN MSG 
Server 

Network domain security with 3GPP UTRAN/GERAN MSC Server shall be provided by NDS/IP according to 

TS 33.210 [21] with integrity protection and confidentiality. This shall be applied whenever signalling messages (e.g. 

containing security context) are transferred on the Sv reference point. 

NOTE 2: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection 
according to TS 33.210 [21]. 
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Annex A (informative): 
Determination of Neighbour Cell List 

This annex describes example algorithms for determination of Neighbour Cell List (NCL) for SRVCC operation. In 
case of SRVCC to GERAN/UTRAN it is also clarified when the E-UTRAN includes a SRVCC indication in the 
Handover Required message. 

~AA SRVCC from E-UTRAN to 3GPP2 1xCS 

E-UTRAN may determine the NCL as follows: 

- If the "SRVCC operation possible" indication is set to "true" (i.e. both EPC and UE are SRVCC capable), then: 

- if there is an established QCI=1 bearer for this UE, then Ix cells may be included as candidate target cells in 
the NCL; 

- if there is no established QCI=1 bearer for this UE, then Ix cells are not included in the NCL. 

- If the "SRVCC operation possible" indication is set to "false" (i.e. either EPC or UE is not SRVCC capable), 
then Ix cells are not included in the NCL. 

A.2 SRVCC from E-UTRAN to GERAN/UTRAN 

E-UTRAN may determine the NCL, as well as the need to signal a SRVCC indication, as follows: 

- If the "SRVCC operation possible" indication is set to "true" (i.e. both EPC and UE are SRVCC capable), then 
VoIP-incapable cells may be included as candidate target cells in the NCL, regardless of the presence of 
established QCI=1 bearers for this UE. Moreover: 

- if there is an established QCI=1 bearer for this UE and the selected target cell is VoIP-capable, then E- 
UTRAN does not include a SRVCC indication in the Handover Required message; 

- if there is an established QCI=1 bearer for this UE and the selected target cell is VoIP-incapable, then E- 
UTRAN includes a SRVCC indication in the Handover Required message; 

if there is no established QCI=1 bearer for this UE, then E-UTRAN does not include a SRVCC indication in 
the Handover Required message; 

- If the "SRVCC operation possible" indication is set to "false" (i.e. either EPC or UE is not SRVCC capable), 
then E-UTRAN does not include a SRVCC indication in the Handover Required message. Moreover: 

- if there is an established QCI=1 bearer for this UE, then VoIP-incapable cell are not be included in the NCL; 
if there is no established QCI=1 bearer for this UE, then VoIP-incapable cells may be included in the NCL. 

a!3 SRVCC from UTRAN (HSPA) to GERAN/UTRAN 

Similar logic may be used as in clause A.2 by replacing E-UTRAN with UTRAN. 
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